Fix RTSP server crash on TCP transport connect by Copilot · Pull Request #602 · esp-cpp/espp

Copilot · 2026-02-19T14:59:58Z

RTSP server becomes permanently unresponsive after a client connects requesting TCP interleaved transport (e.g., Home Assistant). No subsequent clients can connect until reboot.

Changes

Fix data race on sessions_ map — accept_task_function was mutating sessions_ without holding session_mutex_, while session_task_function iterates/erases under that same mutex on a different thread. Added lock guard around the emplace.
Teardown session on failed SETUP — After rejecting TCP transport with 461, the session was left alive (closed_=false, session_active_=false) as a zombie. Now calls teardown() so session_task_function cleans it up on the next iteration.
Include CSeq in 461 response — The "Unsupported Transport" response was missing the CSeq header, violating RTSP protocol.

// rtsp_server.cpp — accept_task_function
{
  std::lock_guard<std::mutex> lk(session_mutex_);
  sessions_.emplace(session_id, std::move(session));
}

// rtsp_session.cpp — handle_rtsp_setup
if (!parse_rtsp_setup_request(request, rtsp_path, client_rtp_port, client_rtcp_port)) {
  teardown();
  return false;
}

// rtsp_session.cpp — parse_rtsp_setup_request (TCP rejection)
int sequence_number = 0;
parse_rtsp_command_sequence(request, sequence_number);
send_response(461, "Unsupported Transport", sequence_number);

Original prompt

This section details on the original issue you should resolve

<issue_title>RTSP stream crashes on TCP connect</issue_title>
<issue_description>### Answers checklist.

I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.

I have searched the issue tracker for a similar issue and not found a similar issue.

What is the expected behavior?

v 1.0.34
I know TCP is not supported, but as soon as the client forces this anyway no other clients can connect until reboot.
tried to fix myself without any luck.
So if TCP is not supported at least it should not make the system unworkable.

What is the actual behavior?

That after 1 client uses tcp others are still able to connect.

Steps to reproduce.

use rtsp in a project
    espp::RtspServer::Config rtsp_cfg;
    rtsp_cfg.port = 8554;

    espp::RtspServer server{rtsp_cfg};
    vTaskDelay(1000 / portTICK_PERIOD_MS); // 1 second
    server.start();
and a simple for loop
 while (true)
    {
        camera_fb_t *fb = esp_camera_fb_get();
        if (!fb)
            continue;
       // --- RTSP send ---
        std::span<const uint8_t> jpeg_span(fb->buf, fb->len);
        server.send_frame(espp::JpegFrame(jpeg_span));
      esp_camera_fb_return(fb);
   }
connect with home assistant like this
type: custom:webrtc-camera
streams:
  - url: rtsp://192.168.170.31:8554/stream
Build or installation Logs.
More Information.

No response</issue_description>

<agent_instructions>Please look through the rtsp component code as well as the socket component code and make any additional bufixes necessary.</agent_instructions>

Comments on the Issue (you are @copilot in this section)
@finger563 @bkbartk thanks for reporting this! Can you please enable logging on the rtsp server and provide the logs so I can see what the server is doing in this state?

Fixes RTSP stream crashes on TCP connect #598

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Three fixes: 1. Fix race condition on sessions_ map - accept_task_function now locks session_mutex_ when modifying sessions_, matching the locking in session_task_function that iterates/erases sessions. 2. Teardown session after failed SETUP - when TCP transport is rejected (or any SETUP parse failure), the session is properly torn down so it gets cleaned up instead of remaining as a zombie. 3. Include CSeq in 461 response - the "Unsupported Transport" response now includes the sequence number per RTSP protocol. Co-authored-by: finger563 <213467+finger563@users.noreply.github.com>

Co-authored-by: finger563 <213467+finger563@users.noreply.github.com>

github-actions · 2026-02-19T15:24:27Z

✅Static analysis result - no issues found! ✅

Copilot

Pull request overview

This PR fixes a critical crash in the RTSP server that occurs when clients request TCP transport (e.g., Home Assistant connections). The server was becoming permanently unresponsive due to a race condition and zombie sessions.

Changes:

Fixed data race on sessions_ map by adding mutex protection during session insertion
Added session teardown on failed SETUP requests to prevent zombie sessions
Fixed RTSP protocol violation by including CSeq header in 461 "Unsupported Transport" responses

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
components/rtsp/src/rtsp_server.cpp	Added mutex lock guard around `sessions_.emplace()` to fix race condition between accept_task and session_task threads
components/rtsp/src/rtsp_session.cpp	Added `teardown()` call on SETUP failure and included CSeq in TCP transport rejection response

components/rtsp/src/rtsp_session.cpp

… with an error to the client

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Copilot · 2026-02-21T23:01:08Z

components/rtsp/src/rtsp_session.cpp

    logger_.error("TCP transport is not supported");
-    // TODO: this doesn't send the sequence number back to the client
-    send_response(461, "Unsupported Transport");
+    handle_rtsp_invalid_request(request, 461, "Unsupported Transport");


The magic number 461 should be defined as a named constant (e.g., RTSP_UNSUPPORTED_TRANSPORT = 461) to improve code readability and maintainability.

Copilot · 2026-02-21T23:01:08Z

components/rtsp/include/rtsp_session.hpp

  /// Handle an invalid RTSP request
  /// @param request The request to handle
+  /// @param code The response code to send (default: 400)
+  /// @param message The response message to send (default: "Bad Request")
  /// @return True if the request was handled successfully, false otherwise


The function documentation should be updated to explain that this method now handles both generic invalid requests and specific protocol errors, and clarify when custom codes/messages should be used versus defaults.

Suggested change

/// Handle an invalid RTSP request

/// @param request The request to handle

/// @param code The response code to send (default: 400)

/// @param message The response message to send (default: "Bad Request")

/// @return True if the request was handled successfully, false otherwise

/// Handle an invalid RTSP request.

///

/// This helper is used both for generic invalid requests (for example, malformed

/// or incomplete RTSP messages) and for specific protocol or semantic errors

/// detected while parsing or validating a request.

///

/// If no explicit status is provided, a generic `400 Bad Request` response is

/// sent to the client.

///

/// @param request The request to handle.

/// @param code The RTSP status code to send. Use the default (400) for generic

/// invalid requests, and provide a more specific code (for example,

/// 401, 404, 405, or 454) when reporting a particular protocol error.

/// @param message The RTSP reason phrase to send. Defaults to "Bad Request" and

/// should normally be overridden when sending a custom @p code

/// to better describe the specific error condition.

/// @return True if the request was handled successfully, false otherwise.

Initial plan

123cf61

Copilot AI assigned Copilot and finger563 Feb 19, 2026

Copilot started work on behalf of finger563 February 19, 2026 15:00 View session

Copilot AI and others added 3 commits February 19, 2026 15:07

Fix RTSP server crash on TCP transport connect

e9218a5

Co-authored-by: finger563 <213467+finger563@users.noreply.github.com>

Remove codeql artifact

21cad23

Co-authored-by: finger563 <213467+finger563@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix RTSP stream crash on TCP connection~~ Fix RTSP server crash on TCP transport connect Feb 19, 2026

Copilot AI requested a review from finger563 February 19, 2026 15:10

Copilot finished work on behalf of finger563 February 19, 2026 15:10

finger563 marked this pull request as ready for review February 19, 2026 15:32

Copilot AI review requested due to automatic review settings February 19, 2026 15:32

Copilot started reviewing on behalf of finger563 February 19, 2026 15:34 View session

Copilot AI reviewed Feb 19, 2026

View reviewed changes

components/rtsp/src/rtsp_session.cpp Show resolved Hide resolved

finger563 added 3 commits February 21, 2026 16:41

Merge branch 'main' into copilot/fix-rtsp-stream-crash-tcp

c8ebb26

ensure all false return paths from parse_rtsp_setup_request respond…

a86ad63

… with an error to the client

update to use existing function modified instead of new function

0b59735

finger563 requested a review from Copilot February 21, 2026 22:56

finger563 approved these changes Feb 21, 2026

View reviewed changes

Copilot AI reviewed Feb 21, 2026

View reviewed changes

Copilot started reviewing on behalf of finger563 February 21, 2026 23:18 View session

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

Fix RTSP server crash on TCP transport connect#602

Fix RTSP server crash on TCP transport connect#602
Copilot wants to merge 7 commits intomainfrom
copilot/fix-rtsp-stream-crash-tcp

Copilot AI commented Feb 19, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Feb 19, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 21, 2026

Uh oh!

Copilot AI Feb 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-  /// Handle an invalid RTSP request
-  /// @param request The request to handle
-  /// @param code The response code to send (default: 400)
-  /// @param message The response message to send (default: "Bad Request")
-  /// @return True if the request was handled successfully, false otherwise
+  /// Handle an invalid RTSP request.
+  ///
+  /// This helper is used both for generic invalid requests (for example, malformed
+  /// or incomplete RTSP messages) and for specific protocol or semantic errors
+  /// detected while parsing or validating a request.
+  ///
+  /// If no explicit status is provided, a generic `400 Bad Request` response is
+  /// sent to the client.
+  ///
+  /// @param request The request to handle.
+  /// @param code The RTSP status code to send. Use the default (400) for generic
+  ///             invalid requests, and provide a more specific code (for example,
+  ///             401, 404, 405, or 454) when reporting a particular protocol error.
+  /// @param message The RTSP reason phrase to send. Defaults to "Bad Request" and
+  ///                should normally be overridden when sending a custom @p code
+  ///                to better describe the specific error condition.
+  /// @return True if the request was handled successfully, false otherwise.

Comments

Conversation

Copilot AI commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

What is the expected behavior?

What is the actual behavior?

Steps to reproduce.

Build or installation Logs.

More Information.

Comments on the Issue (you are @copilot in this section)

Uh oh!

github-actions bot commented Feb 19, 2026

✅Static analysis result - no issues found! ✅

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Feb 19, 2026 •

edited

Loading